白话Java NIO

目前Java支持的IO共有三种：

本文主要通过对比BIO和NIO，尽量通俗易懂的介绍NIO，重在有个整体认识，不深入代码实现，也不讨论同步/异步（因为还没弄懂-_-!。。懂了再补）。

IO

I/O，即input/output，可以说任何端到端的通信，大体都由三部分组成：输入–>传输–>输出。常见的有文件读写、网络通信，都属于IO。

BIO大家都熟悉，在BIO中：

以常见的Socket服务器为例：

阻塞造成的：如果连接较多，而且每个连接（Stream）上的数据量都很小，那么大多数的线程，大部分时间都是处于阻塞状态的（因为没有数据它要干等着啊），所以CPU大部分时间都在忙于线程调度，效率低下
面向字节造成的：因为每次读写都是一个字节，不仅慢，而且没有任何其他操作的余地，比如数据前后移动、定位等（但这个是可以通过字节数组手动改善的，即每次读写一个字节数组）

只要反着上边说的情况，就是它的适用场景：

针对BIO的缺点，在JDK 1.4推出了NIO，主打非阻塞：

每一个端到端的连接，从Stream变成了Channel
输入输出面向的基本单位，从字节变成了缓冲区（本质就是一个封装好的字节数组）
Channel有阻塞/非阻塞两种模式可选，非阻塞模式下，没有数据时就不用干等着了
不干等着，又没数据，那能干嘛呢？那就去看看其他Channel有没有数据呗？为了配合Channel的非阻塞模式，新添加了一个Selector，Selector到Channel是一对多的关系，相当于是Channel的管理者。以前数据向Stream要，现在向Selector要，Selector会把已经有数据的Channel挑选准备好，只有所有Channel都没数据时，在Selector这里才会阻塞。所以等于把阻塞的级别提高了一个维度，大大降低了阻塞的可能。可以类比进程和线程的关系：当且仅当一个进程中所有线程都死了，这个进程才算死了。

还以常见的Socket服务器为例：

监听客户端连接请求的Socket变成了ServerSocketChannel，设置成非阻塞模式，然后把它交给Selector来管理，并告诉Selector它只负责连接请求，不负责读写，因为不阻塞，所以不用单独开线程
无限循环，阻塞式地向Selector索要有数据的Channel：
a. 如果是连接请求来了，那就把新的连接SocketChannel也交给Selector来管理，并告诉Selector它是负责读写数据的
b. 如果是需要读写的数据来了（即已有的连接），那就进行数据读写处理
c. 如果当前所有的Channel都没数据，那就在Seletor这里阻塞着，直到至少一个Channel有数据为止
d. 虽然在Seletor这里也有可能阻塞，但仍不需要单独开线程，就在主线程办。为什么呢？如果Selector阻塞了，说明当前没有什么数据可处理的，都没事干了，主线程阻塞歇着又有何妨呢？

排队造成的：什么是排队呢？当多个Channel都有数据时，只有单个线程通过Selector顺序处理它们，不就等于在排队处理吗？那么，如果每个Channel数据量都很大，零并发，效率低下
以上问题，可以通过增加Selector数量，减小单个Selector管理的Channel量，增加并发度来缓解，但仍存在排队问题，并没有根本解决

● 连接数多，但每个连接上，数据量小

这时你可能也发现了，那如果连接数多，每个连接上数据量也大时，以上两个就都不适用了？怎么办呢？——AIO，具体还不懂，就不多说了。